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Foreword 


VISION 

As  leaders  of  architecture  in  the  Air  Force,  we  deliver  timely,  relevant,  unambiguous 
information  to  support  informed  decision-making  by  Air  Force  leaders  to  maximize 
military  capabilities  while  optimizing  allocation  of  resources. 


Air  Force  (AF)  decision-makers  are  called  upon  daily  to  make  decisions  across  the  AF,  which  is 
growing  in  complexity,  yet  often  have  to  do  so  without  being  provided  with  objective  analysis  of 
the  second  and  third  order  impacts  of  their  decisions.  By  helping  unravel  the  complexity  of  AF 
systems,  processes  and  programs,  and  presenting  decision-makers  with  clearly  articulated 
analysis,  architecting  can  help  eliminate  the  ‘fog’  associated  with  decision-making  in  a  complex 
environment. 

This  Concept  of  Operations  (CONOPS)  highlights  how  the  use  of  architecture  can  enable  the  AF 
to  maximize  its  contribution  to  full  spectrum  dominance  for  the  joint  warfighter,  and  describes 
how  the  architecting  community  can  use  architecture  to  support  AF  decision-making  at  all  levels. 
Although  intended  for  the  architecting  community,  the  secondary  goal  of  this  CONOPS  is  to 
give  those  outside  the  architecting  community,  including  decision-makers,  an  appreciation  for 
the  role  architecture  can  play  in  the  decision-making  process. 
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Section  I  -  Issue 


A.  Problem  Statement 

"The  great  uncertainty  of  all  data  in  war  is  a  peculiar  difficulty,  because  all  action  must,  to  a  certain 
extent,  be  planned  in  a  mere  twilight,  which  in  addition  not  infrequently  —  like  the  effect  of  a  fog  or 
moonshine  —  gives  to  things  exaggerated  dimensions  and  unnatural  appearance. " 

Carl  von  Clausewitz  -  ‘On  War’ 

Air  Force  (AF)  leaders  make  complex  decisions  on  a  daily  basis  affecting  the  AF  enterprise. 
However,  the  second  and  third  order  effects  of  those  decisions  often  impact  seemingly  disparate 
portions  of  the  enterprise  in  fundamental  ways  (good  or  bad)  that  were  unforeseen  by  the 
decision-maker  simply  because  the  relationship  data  was  not  available  at  the  time  the  decision 
was  made.  Architecture  can  eliminate  some  of  the  “fog”  of  decision-making  by  defining  these 
relationships  in  a  format  the  decision-maker  can  easily  understand. 

Architecture  as  a  decision-making  tool  has  already  had  impact  in  ensuring  compliance  (Clinger- 
Cohen  Act  (CCA),  Joint  Capabilities  Integration  and  Development  System  ((JCIDS),  etc.)  and 
guiding  transformation.  However,  it  is  not  being  used  in  such  a  way  as  to  live  up  to  the  mandate 
and  intent  of  Congress  or  the  vision  of  our  senior  leaders.  The  challenge  is  to  ensure  that  the 
benefits  of  architecture  in  the  decision-making  process  are  well  understood  and  that  architecture 
becomes  a  valued  and  integral  part  of  the  decision-making  process  across  the  AF. 


B.  Architecture  Vision 

The  vision  for  architecture  is  to  enable  the  delivery  of  timely,  relevant,  unambiguous  information 
to  support  informed  decision-making  by  Air  Force  leaders  to  maximize  military  capabilities 
while  optimizing  allocation  of  resources. 

The  goal  is  to  use  architecture  to  unravel  the  complexity  of  our  systems,  processes,  and  programs 
to  reveal  their  interdependent  relationships  to  decision-makers,  in  an  easily  understandable 
format,  so  they  may  be  adequately  considered  as  decisions  are  made.  In  essence,  architecture 
ought  to  be  used  as  a  tool  to  eliminate  redundancy,  build  efficiency,  and  maximize  resource 
distribution  to  ultimately  increase  combat  effectiveness  of  the  AF. 

C.  Purpose  of  the  CON  OPS 

The  purpose  of  this  CONOPS  is  to  articulate  how  architecture  will  be  built  and  governed  to 
support  the  decision-making  process.  Additionally,  it  will  present  a  model  of  how  the 
architecting  community  will  ensure  architecture  supports  AF  decision-making  at  all  levels. 
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This  CONOPS  will  also  set  the  context  to  improve  architecting  processes,  further  refine 
architectures,  and  provide  architecting  organizations  with  a  refreshed  focus  on  the  concepts 
necessary  for  supporting  decision-making,  supporting  transformation,  and  optimizing 
governance.  Finally,  it  will  ensure  architecting  efforts  are  organized  and  executed  effectively. 


D.  Relationship  to  other  AF  Management  Processes 

This  document  addresses  AF  processes  not  currently  documented  in  any  specific  CONOPS.  This 
Architecting  CONOPS  supports  the  following  specific  AF  processes: 

•  Panel  Support  process 

•  Capability  Based  Planning  Process 

•  Planning  Programming  Budgeting  Execution  Process 

•  Portfolio  Management  Process 

•  System  Development  and  Acquisition  Process 

Section  II  -  Overview 

A.  Synopsis 

When  fully  integrated  in  AF  decision-making  processes,  the  use  of  architecture  will  ensure 
maximum  combat  effectiveness  by  reducing  redundancy,  ensuring  interoperability,  and  helping 
the  AF  allocate  resources  in  the  most  efficient  means  possible.  Specifically,  the  use  of 
architecture  will  help  decision-makers  understand: 

•  Requirement  priorities  and  requirement  conflicts 

•  Gaps,  overlaps,  and  emerging  functional  capabilities  and  impact  on  the  warfighter 

•  AF  Enterprise  interdependencies  and  interfaces 

•  Behavioral  impact  of  change,  such  as  performance,  power  demand,  network  demand 

•  Total  ownership  cost 

•  Potential  tradeoffs 

B.  Operational  View  ( OV)-l 

The  following  figure  depicts  the  overall  environment  described  in  this  CONOPS.  In  order  to  successfully 
integrate  architecture  into  the  decision-making  process,  work  is  required  across  the  use,  govern,  and 
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build  environments,  as  detailed  below. 


Use 


Air  Staff  Decision  Makers 
MAJCOM  Decision  Makers 
Program  Decision  Makers 


People 


Arch  Governance  Boards 
Arch  IV&V  Teams 
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Decision  Making  Rules 
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Process 


Arch  Governance  Rules 


Decision  Making  Processes 


Architecture  Governance  Processes 


Decision  Making  Mechanisms  Tech  Arch  Governance  Mechanisms 


Air  Staff  Architects 
(A1  through  An,  FM,  AQ, ...) 


MAJCOM  Architects 


Program  Architects 


Build  (including  Analytics) 


Figure  1:  Architecting  Environment 

Use  Environment.  The  Use  environment  includes  people,  processes,  and  technologies  involved 
in  AF  decision-making.  Those  involved  in  the  decision-making  processes  are  the  “users”  of 
architecting  processes.  These  decision-making  processes  include  processes  such  as  those  used  by 
AF  panels  in  the  AF  Corporate  Structure  (e.g.  the  acquisition  or  Capabilities  Review  and  Risk 
Assessment  processes).  Examples  where  architecture  is  used  in  this  environment  include 
describing  warfighting  requirements,  identifying  duplications  and  gaps,  providing  analysis  for 
Program  Objective  Memorandum  (POM)  efforts,  and  ensuring  compliance  for  processes  such  as 
JCIDS.  In  the  Use  environment,  architecture  is  a  tool  to  support  decision-making  and  is 
described  from  an  architect’s  perspective  as  “governing  with  architecture.” 

The  Govern  Environment.  The  Govern  environment  consists  of  people,  processes,  and 
technologies  that  govern  the  quality  of  the  AF  architectures.  Members  in  this  Govern 
environment  are  those  AF  bodies  that  utilize  the  architecture  assessment  and  certification 
processes.  These  processes  and  associated  technologies  are  focused  on  “governing 
architectures”  and  ensuring  that  architectures  are  fit  for  their  intended  purpose. 

Build  Environment.  Finally,  the  Build  environment  includes  those  people,  processes,  and 
technologies  that  support  architecting  for  the  various  areas  such  as  Air  Staff  (including  direct 
reporting  units),  Major  Commands  (MAJCOMs)  (including  forward  operating  agencies  and 
centers),  and  Programs.  Architects  and  analysts  are  members  of  this  environment.  It  not  only 
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includes  building  architectures,  but  analyzing  them  and  constructing  reports  in  support  of  the 
decision-making  processes. 

C.  Description  of  the  Military  Challenge 

As  well  as  confronting  enemy  air,  space  and  cyberspace  power  in  the  future,  the  AF  will  have  to 
deal  with  austere  budget  cycles,  along  with  increasing  complexity  and  interdependencies.  Where 
it  may  once  have  been  possible  for  decisions  regarding  individual  systems  or  capabilities  to  be 
made  in  isolation,  the  continued  drive  for  networked  capability  means  that  it  is  essential  for 
decision-makers  to  consider  the  impact  on  the  wider  network.  The  ability  to  make  objective 
decisions  in  this  highly-complex,  networked  environment,  will  determine  how  well  the  AF  is 
positioned  to  dominate  air,  space,  and  cyberspace  in  the  future. 


D.  Desired  Effects 

The  desired  effect  is  to  optimize  the  AF’s  contribution  to  full  spectrum  dominance,  by  providing 
decision-makers  with  objective  analysis  of  the  current  and  future  AF  enterprise. 

Section  III  -  Context 

A.  Time  Horizon 

This  AF  CONOPS  focuses  on  the  Planning,  Programming,  Budgeting  and  Execution  processes 
and  is  designed  to  facilitate  the  associated  decisions  through  objective,  structured,  and 
interrelated  information.  Through  continued  decision- support  across  the  AF  area  of 
responsibility,  the  time  horizon  of  this  CONOPS  and  its  iterations  are  a  continual  process.  The 
planned  initial  effect  is  the  FY12  POM  and  FY 13  execution  years. 


B.  Assumptions 

This  CONOPS  assumes  that  the  complexity  of  the  Federal,  DoD,  and  USAF  organizations 
requires  an  objective  decision-support  “toolbox”  to  effectively  manage  scarce  resources. 
Additionally,  it  is  assumed  that  one  of  the  tools  in  this  “toolbox”  is  generically  identified  as 
architecting.  Furthermore,  the  assumption  is  that  at  every  layer  of  the  enterprise,  architectures 
are  required  to  support  that  particular  layer’s  decisions. 

C.  Risks 

The  following  risks  were  derived  from  a  community  of  stakeholders:  misallocated  resources, 
sub-optimal  AF  capabilities,  unstable  economies  (across  layers),  exposure  to  threats,  loss  of 
architecting  efficiency,  loss  of  ability  to  audit,  loss  of  credibility,  loss  of  enterprise  efficiency, 
and  loss  of  funding.  These  categories  are  briefly  explained  as: 


10 


•  Misallocated  resources  refers  to  poorly  aligning  people  and  funds  to  achieve  identified 
goals 

•  Sub-optimal  AF  capabilities  refers  to  the  ineffectual  ability  to  achieve  desired  effects 

•  Unstable  economies  refers  to  negative  second  and  third  order  economic  effects  of  AF 
investment 

•  Exposure  to  threats  refers  to  a  heightened  risk  environment  across  operational  levels 

•  Loss  of  architecting  efficiency  refers  to  wasted  architecture  resources 

•  Loss  of  audit-ability  refers  to  clouded  traceability  and  measurability  of  decisions  and 
resources 

•  Loss  of  architecture  credibility  refers  to  low  architecture  data/information  confidence 

•  Loss  of  enterprise  efficiency  refers  to  decreased  mission  effectiveness 

•  Loss  of  funding  refers  to  reduced  enterprise  resources 


In  response  to  the  identified  risks,  the  following  risk  mitigations  were  derived:  relevant  and 
effective  application  of  architecture,  govern  architecture  with  appropriate  communications, 
effective  architectural  content  and  relationships,  enhance  architectural  quality.  These  categories 
are  briefly  explained  as: 

•  Relevant  and  affective  application  of  architecture  refers  to  the  appropriate  development 
use  and  governance  of  architecture 

•  Govern  architecture  with  appropriate  communications  refers  to  the  appropriate 
standardization  of  architecture  development  and  known  placement  within  the  federated 
architecture  community 

•  Effective  architectural  content  and  relationships  refers  to  the  appropriate  federation  and 
integration  of  architectures  to  support  the  identified  purpose  and  scope 

•  Enhance  architectural  quality  refers  to  improving  the  data  used,  structure  of,  and  analysis 
of  architectures. 


These  risks  and  mitigations  have  been  placed  into  a  risk  identification  and  mitigation  table.  This 
table’s  identified  mitigation  plans  and  risks  are  addressed  in  this  CONOPS. 
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Table  1  Risk  Identification  and  Mitigation1 


Risk 

ID 

Risk  Description 

Preliminary  Risk 

Mitigation 

Residual  Risk 

Effect 

Frequency 

Impact 

Effect 

Frequency 

Impact 

1 

Misallocated 

resources 

Critical 

Frequent 

Extremely 
High  Risk 

Relevant  &  Effective 
Application  of  Architecture 

Marginal 

Seldom 

Low  Risk 

2 

Sub-optimal  USAF 
Capabilities 

Critical 

Occasional 

High  Risk 

Relevant  &  Effective 
Application  of  Architecture 

Marginal 

Unlikely 

Low  Risk 

3 

Unstable  Economies 

Catastrophic 

Seldom 

High  Risk 

Relevant  &  Effective 
Application  of  Architecture 

Critical 

Unlikely 

Low  Risk 

4 

Exposure  to  Threats 

Critical 

Frequent 

Extremely 
High  Risk 

Relevant  &  Effective 
Application  of  Architecture 

Marginal 

Seldom 

Low  Risk 

5 

Loss  of  Architecting 
Efficiency 

Critical 

Frequent 

Extremely 
High  Risk 

Govern  Architecture  with 
Appropriate 
Communications 

Negligible 

Unlikely 

Low  Risk 

6 

Loss  of  Audit-ability 

Marginal 

Likely 

Moderate 

Risk 

Effective  Architectural 
Content  &  Relationships 

Marginal 

Unlikely 

Low  Risk 

7 

Loss  of  Architecture 
Credibility 

Critical 

Frequent 

Extremely 
High  Risk 

Enhance  Architecture 
Quality 

Marginal 

Seldom 

Low  Risk 

8 

Loss  of  Enterprise 
Efficiency 

Critical 

Likely 

High  Risk 

Relevant  &  Effective 
Application  of  Architecture 

Marginal 

Seldom 

Low  Risk 

9 

Loss  of  Funding 

Catastrophic 

Likely 

Extremely 
High  Risk 

Govern  Architecture  with 
Appropriate 
Communications 

Critical 

Occasional 

High 

Risk 

Section  IV  -  Employment  Concept 

A.  High-Level  Context 

The  high-level  context  that  relates  to  AF  architecting  activities  is  depicted  in  Figure  2.  The  key 
lanes  of  activity  include  decision-making,  architecting,  and  transformation  processes,  which 
occur  at  multiple  levels.  For  example,  the  Department  of  Defense  (DoD)  level  includes  decision¬ 
making  processes  at  the  department  level  and  covers  architecting  that  needs  to  occur  at  the 
department  level  to  support  the  decision-making  processes  and  guide  the  department  level 
changes.  Likewise,  within  the  AF  there  are  key  decision-making  processes  at  the  Air  Staff, 
MAJCOM,  and  Program  levels.  These  processes  can  all  be  inter-related  through  the  population 
and  use  of  architecture  data. 

The  relationships  between  the  architecting  activities  are  depicted,  in  Figure  2,  with  different 
arrows  that  have  specific  foci.  Between  the  architecture  and  decision-making  processes,  the  red 

1  The  Open  Group  Architecture  Framework  (TOGAF)  9.0  Part  III  Risk  Management 
(http://www.opengroup.org/architecture/togaf9-doc/arch/ ) 
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arrows  denote  architecture  providing  decision-support.  Likewise,  the  blue  arrow  between  the 
architecture  and  transformation  denotes  the  concept  that  architecture  must  guide  the 
transformation  in  such  a  way  as  to  maintain  the  intent  of  the  decision  made.  Finally,  the  purple 
arrow  denotes  a  two-way  relationship,  one  of  which  is  architecture  compliance,  and  the  other  is 
reflection  between  architectures.  Architectures  should  adhere  to  the  rules  of  other  architectures 
if  there  is  interdependency  -  this  is  compliance.  When  there  is  interdependency  between 
architectures  this  should  be  appropriately  represented  in  each  architecture  -  this  is  reflection. 


Decision  Making  Architectures  Transformations 

Processes 


<  >  Guidance 

<  »  Compliance  and  reflection 

- ►  Decision  support 

Figure  2:  High  Level  Relationships 

B.  Use,  Build,  and  Govern  Concepts 

Use  Concept.  Figure  3  highlights  the  two  major  uses  of  architecture:  to  support  decision-making 
at  the  various  related  levels  and  to  guide  the  transformation  associated  with  any  decision.  To 
serve  these  purposes,  architecture  data  must  be  collected  specifically  to  support  the  needs  of 
decision-makers  and  must  include  the  rules  established  that  ensure  the  intent  of  decisions  are 
realized.  As  the  types  of  decisions  made  depend  on  the  level  (i.e.,  policy  decisions  at  the  higher 
levels  and  program/engineering  decisions  at  the  lower  levels)  it  is  not  possible  to  create  a  single 
template  for  all  architectures,  but  there  will  be  a  minimum  set  of  standard  architecture  data  that 
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spans  all  architectures  to  ensure  decisions  are  implemented  throughout  the  entire  decision¬ 
making  chain. 

The  linkage  between  the  decision-making  and  the  transformation  is  shown  in  Figure  3.  Without 
maintaining  those  linkages  and  interdependencies,  it  is  unlikely  that  the  intent  of  the  original 
decision  will  be  met.  Architectures  hold  the  context  and  rules  necessary  to  maintain  the 
interdependencies.  As  such  the  architecture  should  be  used  to  guide  and  govern  the 
transformation  in  the  context  of  the  decision  made.  This  re-enforces  the  concept  of  governing 
with  architecture. 


Architectures  used  to  Architectures  used  to 

support  decision  making  guide  transformations 


< — ►  Guidance 

+ — >  Complianceand reflection 
»  Decision  support 

i — ►  Transformation  governance  (Govern  vsith  Architecture) 

Figure  3:  Use  of  Architectures 

Build  Concept.  The  architectures  in  Figure  4  are  built  to  support  decision-making  and  guide  the 
resulting  transformation.  They  must  also  be  built  to  ensure  the  appropriate  context  is  maintained 
to  deliver  the  intended  outcomes,  and  that  rules  are  communicated  to  partnering  organizations 
that  will  help  realize  those  outcomes.  Fundamentally,  architecting  must  not  be  done  in  a  vacuum 
-  it  must  be  done  collaboratively  and  the  architecting  process  must  include  stakeholder 
involvement.  The  stakeholders  must  include  decision-makers,  those  that  will  develop  and  deploy 
the  transformation,  and  those  partnering  organizations  that  support  the  transformation. 
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Architectures  built  for  purpose  of  supporting  separate, 
yet  related,  decision  making  and  transformations 


Decision  Making 
Processes 


Architectures 


Transformations 


DoD  Rules  * - *  DoD  Changes 


AF  Rules  +* 

- 1 


MAJCOM  Rules  «- 

>  i 


-+Air  Forces  Changes 


-►  MAJCOM  Changes 


Program  Rules  — *  Program  Changes 


*—  >  Guidance 
* — ►  Compliance 
»  Decision  support 

Figure  4:  Building  Architectures 

Govern  Concept.  Architecture  governance  is  about  governing  architecture  quality,  to  ensure 
outcomes  are  realized.  Figure  5  depicts  the  major  areas  associated  with  architecture  governance, 
which  is  accomplished  in  two  dimensions.  First,  there  is  a  ‘fit-for-purpose’  assessment  to  ensure 
the  quality  of  data  in  the  architecture  supports  the  appropriate  decision-making  process  and 
guides  the  transformation  effort.  This  should  be  accomplished  through  stakeholder  review  of  the 
architecture  data.  The  second  type  of  assessment  addresses  compliance  to  ensure  the 
architectures  are  complete,  adhere  to  the  rules  of  related  architectures,  and  the  rules  of 
developing  architectures,  including  being  fit  for  inclusion  into  the  AF  Enterprise  Architecture 
(EA)  (otherwise  referred  to  as  ‘fit-for-federation’).  This  ensures  that  architectures  can  be  easily 
used  and  understood  -  as  required  by  their  inter-relationships. 
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Architectures  assessed  as  “fit  for  purpose”  and 
“compliance”  to  ensure  decisions  stick 


Decision  Making 


Transformations 

Fit  for  purpose 

«  »  DoD  Changes 


Architectures 

DoD  Rules 

t 

Com/^iant 

AF  Rules 

t 

Com^iant 

MAJCOM  Rules 

f 

Compliant 

▼  Fit  for  purpose 

Program  Rules  *  »  Program  Changes 


Fit  for  purpose 

< —  - Air  Forces  Changes 


Fit  for  purpose 

* - *  MAJCOM  Changes 


Figure  5:  Governing  Architectures 


C.  Critical  Capabilities 

The  benefits  of  architecting  can  only  be  achieved  when  the  following  three  critical  capabilities 
are  functioning  and  interacting  as  required. 


Effective  Decision-Support  Capability.  In  order  to  achieve  the  desired  end- state,  architectures 
must  be  requirement  driven.  Architects  must  actively  engage  with  the  decision-making 
community,  in  order  to  articulate  the  value  of  using  architecture  as  a  tool  for  objective  decision¬ 
making,  and  to  work  with  decision-makers  to  identify  the  scope  and  purpose  of  the  architecture. 
Architects  must  ensure  that  the  product  delivered  to  the  decision-maker  is  accurate, 
understandable,  and  meets  the  agreed-upon  requirements. 

Optimal  Build  Capability.  In  order  to  meet  the  requirements  of  decision-makers,  it  is  essential 
that  architectures  be  built  to  a  common,  high  standard,  using  consistent,  repeatable  processes  and 
procedures.  Any  data  used  to  build  the  architecture  must  be  shareable,  in  standard  formats,  and 
accurate. 


Functioning  Governance  Capability.  To  assure  the  quality  of  the  architectures  produced,  a 
functioning  governance  capability  and  appropriate  processes  must  be  in  place.  This  governance 
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must  ensure  that  architectures  are  fit-for-purpose  and  are  fit-for-federation  within  the  wider  AF 
EA  and  DOD  EA.  A  certification  process  will  ensure  the  information  decision-makers  are  using 
is  accurate  and  trustworthy.  This  certification  process  will  also  ensure  architectures  can  be  easily 
discovered  and  re-used  wherever  possible  through  the  use  of  architecture  repositories. 


D.  Enabling  Capabilities 

There  are  enabling  capabilities  the  AF  must  possess  in  order  to  support  the  critical  capabilities 
identified  above. 

Ability  to  architect  consistently  in  the  Air  Force.  Defined  architecting  roles,  responsibilities 
and  processes  are  required  across  the  AF  architecture  community.  To  architect  properly, 
organizations  must  possess  the  appropriate  architecting  tools  (which  are  based  on  common 
commercial  standards),  including  modeling  tools  that  support  standards,  and  certified  architects. 
Further,  architecting  organizations  must  maintain  architecture  configuration  control  over  the 
architectures  within  their  purview.  Additionally,  an  official  USAF  Architecture  Community  of 
Practice  will  be  established  to  support  the  collection  of  lessons  learned,  best  practices,  and 
information  sharing.  Policy  will  also  direct  basic  architecture  training  for  appropriate  decision¬ 
makers  at  all  levels. 


Ability  to  optimize  architecting  activities.  AF  architectures  must  consist  of  consumable 
architecture  data  and  content,  which  must  be  accessible,  understandable  and  shareable. 
Additionally,  there  must  be  a  means  to  develop  and  formally  approve  that  data/content.  To  assist 
with  this  effort,  the  Air  Staff  will  maintain  approved,  reference  models  for  use  in  architecting 
efforts.  Additionally,  the  structure  of  the  AF  Architecture  Repository  (AFAR)  will  be 
standardized  to  allow  the  discovery  and  reuse  of  existing  artifacts.  The  AFAR  will  support 
interoperability  with  the  Defense  Architecture  Repository  System  (DARS).  To  further  support 
reuse,  architecture  data  structures  for  a  minimum  set  of  data  will  be  standardized. 

Ability  to  optimize  compliance  processing  and  quickly  ascertain  applicable  criteria. 

The  AF  will  optimize  the  compliance  assessment  processes  and  identify  applicable  compliance 
criteria.  The  capability  must  exist  to  assess  any  architecture  for  compliance  with  any  other 
architecture.  Where  non-compliance  is  identified  the  AF  Chief  Architect  will  recommend  that 
the  AF  Chief  Information  Officer  pursue  measures  to  cease  execution  of  program  funding  until 
compliance  is  established. 

Effective  Communications.  The  benefits  of  architecting  must  be  clearly  articulated  to,  and 
understood  by,  decision-makers.  Architecting  success  stories,  which  demonstrate  how 
architecting  has  been  effective  in  driving  down  costs  and  increasing  capability  to  the  warfighter, 
must  be  captured  and  communicated.  Crucially,  architects  must  refrain  from  using  architecture- 
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specific  language  when  dealing  with  non-specialists  and  must  seek  to  engage  decision-makers 
using  clearly  understood  language.  In  effect,  if  the  benefits  of  using  architecture  cannot  be 
clearly  articulated  and  understood,  it  will  not  be  relevant. 


E.  Sequenced  Actions 

Full  operating  capability  will  be  achieved  when  the  use,  build  and  govern  environments  are  fully 
functioning  and  operating  synergistically.  To  migrate  from  the  current  capability  to  the  full 
operating  capability,  those  procedures  and  processes  that  are  already  optimized  and  functioning 
will  continue  to  be  used.  Action  will  be  taken  to  amend  or  implement  those  capabilities  that  are 
either  sub-optimal  or  lacking  in  total.  As  the  overall  capability  grows  incrementally  in  response 
to  new  requirements  and  the  quality  of  the  underlying  data  improves  in  response  to  the 
governance  structure,  the  architecting  community  will  be  able  to  answer  ever  more  complex 
questions,  across  the  AF  enterprise,  with  ever-increasing  confidence  and  accuracy. 

The  sequence  of  actions  that  will  improve  the  AF  architecting  capabilities  are  depicted  in  Figure 
6.  There  are  connected  sequences  in  each  of  the  use,  build,  and  govern  environment,  resulting  in 
a  cycle  that  begins  and  ends  in  the  use  environment.  Each  sequence  is  described  below  starting 
with  the  sequence  in  the  “use  environment”  which  is  focused  on  understanding  the  needs  of  the 
decision-making  process. 
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Air  Staff  Architects 
(A1  through  An,  FM,  AQ, ...) 


MAJCOM  Architects 

Build  (including  Analytics) 


Program  Architects 


Figure  6:  Sequenced  Actions 


1.  Use  Environment 

To  realize  the  potential  of  architecture,  it  is  essential  to  ascertain  the  information  requirements  of 
decision-makers  and  leverage  the  power  of  the  data  within  architecture  repositories  to  meet  those 
requirements.  This  method,  shown  in  Figure  7,  can  be  replicated  across  the  AF  by  architecture 
support  organizations  at  all  levels  and  should  be  used  in  the  front  end  of  any  architecture 
development  effort. 


Figure  7  Architecture  Link  to  Decision  Support  Processes 


Scope.  The  first  step  in  leveraging  architecture  is  to  scope  the  problem.  Architecture 
support  personnel  must  determine  what  types  of  information  are  required  by  decision¬ 
makers  in  a  given  process. 
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•  Understand  the  Process.  In  order  to  gain  context  of  the  problem  the  architecture  support 
personnel  must  gain  an  understanding  of  the  process  in  which  the  complex  decisions  are 
made. 

•  Define  Information  Flow.  After  understanding  the  process,  the  architecture  support  team 
can  begin  to  define  the  information  flows  resident  in  the  process. 

•  Identify  Leverage  Points.  Now,  the  architecture  support  team  is  in  a  position  to 
determine  where  in  the  process  architecture  can  be  leveraged  to  fully  inform  the  decision 
makers  being  supported. 

•  Evaluate  and  choose  Course  of  Action  (COA).  Finally,  the  architect  evaluates  the 
information  and  generates  a  course  of  action  to  deliver  the  architecture  support  necessary 
for  the  decision-maker. 

2.  Build  Environment 

2 

The  following  sequenced  actions  ,  as  shown  in  Figure  8,  address  the  “build  environment.” 


r 

Manage  Change 

Y 

A _ 

_ k 

Manage  Requirements 

Figure  8:  Architecture  Build  Process 

V 

•  Establish  Framework  and  Principles.  This  action  ensures  commitment  to  success  by 
establishing  the  expectations,  framework  and  principles  for  proceeding.  The  following 
must  also  be  documented:  constraints  on  the  work,  the  people  responsible  for  performing 
architecture  work,  where  they  are  located,  and  their  responsibilities,  the  scope  and 
assumptions  (particularly  in  a  federated  architecture  environment),  and  methods  to  be 
employed. 

•  Develop  Architecture  Project  and  Context.  The  next  action  ensures  that  this 
architecture  development  has  proper  recognition  and  endorsement  from  the  management 
of  the  enterprise,  as  well  as  the  support  and  commitment  of  the  necessary  line 
management. 


2  This  set  of  sequenced  actions  is  based  on  TOGAF™  9.0.  TOGAF  is  a  trademark  of  The  Open  Group. 
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•  Develop/Update  Required  Architecture  Views.  The  next  action  is  the  core  architecture 
development  and/or  maintenance  activity,  which  should  be  planned  according  to  the 
specific  needs  of  the  stakeholders. 

•  Identify  Opportunities  and  Solutions.  Once  the  architecture  is  complete,  the  next  step 
is  to  move  toward  the  transformation.  Initial  steps  include  understanding,  evaluating  and 
selecting  the  options  identified  in  the  development  of  the  various  target  architecture 
views. 

•  Create  Migration  Plan.  The  objective  of  this  next  action  is  to  sort  the  various 
implementation  projects  into  priority  order.  Activities  include  assessing  the 
dependencies,  costs  and  benefits  of  the  various  migration  projects. 

•  Govern  Implementation.  After  the  migration  plan  has  been  established  (funded  and 
allocated)  it  is  time  to  communicate  the  architecture  compliance  criteria  for  each 
implementation  project  and  construct  an  architecture  agreement  that  will  be  used  to 
govern  the  overall  implementation  and  deployment  process. 

•  Perform  Change  Management.  Throughout  the  sequence  of  actions,  it  is  important  to 
establish  and  execute  an  architecture  change  management  process. 

•  Engage  Requirements  Management.  There  will  also  be  continued  engagement  with  the 
requirements  management  process  to  ensure  requirements  are  identified,  stored,  and 
represented  throughout  the  relevant  sequenced  actions. 

3.  Govern  Environment 

The  following  two  sequenced  actions  address  the  “govern  environment.”  The  first  set  of 
sequenced  actions  addresses  architecture  approval,  while  the  second  set  addresses  architecture 
certification.  The  following  sequenced  actions  address  the  “govern  environment.” 

Approval.  The  sequenced  actions  depicted  in  Figure  9  ensure  the  architecture  is  fit-for-purpose. 


Figure  9:  Architecture  Approval  Process 

•  Prepare.  The  preparation  action  ensures  that  all  the  logistics  issues  are  addressed  prior  to 
review.  This  includes  scheduling,  obtaining  resources  for  the  review,  communicating  and 
planning. 

•  Review.  The  next  action  is  to  hold  the  review  in  a  facilitated  session  and  ensure  formal 
collection  of  feedback.  The  focus  of  this  review  is  the  content  of  the  architecture. 


3  This  set  of  sequenced  actions  is  based  on  TOGAF™  9.0.  TOGAF  is  a  trademark  of  The  Open  Group. 
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•  Generate  report.  This  action  includes  analyzing  the  feedback  and  documenting  the 
findings  in  a  formal  report. 

•  Assess  report.  The  assess  action  takes  the  report  and  the  intended  purpose  of  the 
architecture  and  documents  whether  the  architecture  is  good  enough  to  proceed  despite 
the  findings  -  this  assessment  is  an  architecture  risk  assessment.  This  action  will  produce 
an  approval  recommendation  in  the  form  of  an  approval  letter  (regardless  of  whether  the 
approval  is  positive  or  negative). 

•  Approve.  The  approve  action  is  the  review  and  sign-off  of  the  approval  letter  by  the 
approval  authority. 

•  Publish.  The  final  action  is  the  publication  of  an  approved  architecture  in  the  appropriate 
repositories. 


Certification.  The  sequenced  actions  depicted  in  Figure  10  ensure  the  architecture  is  fit-for- 
federation. 


Figure  10:  Architecture  Certification  Process 

•  Prepare.  This  action  ensures  that  the  certification  package  is  created  and  sent  to  the 
appropriate  architecture  certification  authority. 

•  Review.  The  architecture  certification  authority  reviews  the  architecture  against  the  AF 
certification  criteria. 

•  Generate  report.  This  action  includes  analyzing  review  feedback  and  documenting  the 
findings  in  a  formal  report. 

•  Assess  report.  The  assess  action  takes  the  report  and  the  intended  purpose  of  the 
architecture  and  documents  whether  the  architecture  is  good  enough  to  proceed  despite 
the  findings  -  this  assessment  is  an  architecture  risk  assessment.  This  action  will  produce 
a  certification  recommendation  in  the  form  of  a  certification  letter  (regardless  of  whether 
the  approval  is  positive  or  negative). 

•  Certify.  The  certify  action  is  simply  the  review  and  sign-off  of  the  certification  letter  by 
the  architecture  certification  authority. 

•  Publish.  The  final  action  is  the  publication  of  a  certified  architecture  in  the  appropriate 
repositories. 
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F.  End  State 


The  end  state  will  be  achieved  when  the  architecture  capability  described  is  integrated  into  AF 
decision-making  processes  and  enables  AF  decision-makers  to  make  objective  decisions 
concerning  capability  enhancement  and  resource  allocation  across  the  AF  enterprise. 


G.  Top-Level  Activity  Models 

The  High  Level  Activities  depicted  in  Table  2,  are  derived  from  the  roles  and  responsibilities  of 
organizations  found  in  AF  Architecting  Policy  (AFPD  33-4  and  AFI  33-401).  Each  activity 
corresponds  with  an  organizational  level  and  the  respective  Architecture  Operational 
Environment  (Build,  Use  and  Govern). 


Table  2  High  Level  Activities 


Architecting  Environments 


Use 

Build 

Govern 

0 

R 

G 

L 

E 

V 

E 

L 

DoD 

•  Use  architecture  for  decision¬ 
making 

•  Develop/maintain  DoD 
architectures 

•  Develop/maintain  DoD 
Architecture  Repository 
System 

•  Establish  architecture 
policy 

•  Establish  governance 
structure 

•  Establish  architecture 
strategy 

•  Establish  compliance 
criteria 

AF  Air 

Staff 

•  Develop  design/build  plan 

•  Assess  architectures 

•  Analyze  architecture  impact 

•  Use  architecture  for  decision 
making 

•  Evaluate  AF  Enterprise 
Architecture 

•  Analyze  interdependencies 

•  Train  users 

•  Communicate  to  domains 

•  Develop/maintain  AF 
architectures 

•  Develop/maintain  DoD 
Architecture  Repository 
System 

•  Establish  AF  architecture 
policy 

•  Establish  AF  governance 
structure 

•  Establish  AF  architecture 
strategy 

•  Establish  compliance 
criteria 

•  Certify  architectures 

MAJCOM 

•  Evaluate  COTS  products  for 
interoperability 

•  Develop,  recommend  and 
maintain  AF  Architecture 
Technical  Standards 

•  Train  users 

•  Track  C2  shortfalls  (ISPs, 

ICDs,  analyses) 

•  Use  architecture  for  decision 
making 

•  Conduct  architecture 

assessments 

•  Indentify  related  architectures 

•  Develop  design/build  plan 

•  Prepare  ISP 

•  Develop/maintain 
architectures 

•  Develop  process 
improvements 

•  Implement  architecture  as 
necessary 

•  Build  integrated  baseline 
architecture  models 

•  Implement  AF 

Architecture  Policy 

•  Monitor  use  of 
architecture  and  plan 
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•  Assess  sub-architectures 

•  Analyze  architecture  impact 

•  Analyze  interdependencies 

•  Provide  architecture  training 

•  Communicate  to  domains 

•  Assess  architecture  repository 

Program 

•  Identify  related  architectures 

•  Develop  design/build  plan 

•  Train  users 

•  Prepare  ISP 

•  Develop/maintain 
architectures 

•  Develop  process 
improvements 

•  Implement  architecture  as 
necessary 

•  Build  integrated  baseline 
architecture  models 

•  Comply  with  architecture 
governance 

Section  Y  -  Summary 

While  AF  decision-makers  are  faced  daily  with  having  to  make  decisions  affecting  the  whole  of 
the  AF,  which  is  increasingly  complex  and  interdependent,  they  often  have  to  do  so  without 
knowing  the  second  and  third  order  effects  of  such  decisions.  Although  the  use  of  architecture 
has  already  had  some  success  in  supporting  such  decision-making,  objective  decision-making 
can  only  be  achieved  by  integrating  the  use  of  architecture  into  decision-making  across  all  levels 
of  the  AF. 

This  CONOPs  provides  an  employment  concept  for  the  use  of  architecture  within  the  AF  and 
identifies  those  critical  and  enabling  capabilities  required  to  realize  the  benefits  of  using 
architecture  in  the  decision-making  process.  Fundamentally,  the  CONOPs  recognizes  that  by 
optimizing  the  way  architectures  are  built,  used  and  governed,  AF  decision-makers  will  be  able 
to  make  objective  decisions  regarding  capabilities  and  resources,  therefore  optimizing  the  AF 
contribution  to  full  spectrum  dominance  for  the  Joint  Warfighter. 
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